While software systems continue to grow in size and complexity, business demands continue to require shorter development cycles. This has led software developers to compromise on functionality, time to market, and quality of software products. Furthermore, the increased schedule pressures and limited availability of resources and skilled labor can lead to problems such as incomplete design of software products, inefficient testing, poor quality, high development and maintenance costs, and the like. This may lead to poor customer satisfaction and a loss of market share for companies developing software.
To improve product quality many organizations devote an increasing share of their resources to testing and identifying problem areas related to software and the process of software development. Accordingly, it is not unusual to include a quality assurance team in software development projects to identify defects in the software product during and after development of a software product. By identifying and resolving defects before marketing the product to customers, software developers can assure customers of the reliability of their products, and reduce the occurrence of post-sale software fixes such as patches and upgrades which may frustrate their customers.
Testing and identifying problem areas related to software development may occur at different points or stages in a software development lifecycle. For example, a general software development lifecycle includes a high level requirements/design review, a detailed requirements/design review, code inspection, unit test, system test, system integration test, potentially a performance test, and typically, a user acceptance test. Moreover, as the software development lifecycle proceeds from high level requirements/design review to user acceptance test, costs for detecting and remedying software defects generally increases, e.g., exponentially.
As such, software developers may seek to detect and remedy software defects as early in the software development lifecycle in an effort to avoid the increased risks and costs of detecting and remedying these software defects later in the software development lifecycle. To aid in detecting these software defects, an organization may utilize historical defect data for a project (e.g., a software code project) in order to project future defect patterns and trends for the project.
However, consistently accurate defect projection modeling in complex system integration testing is considered impossible absent significant project history. That is, conventionally, historical defect data for a project (e.g., a software code project) must be available in order to accurately project future defect patterns and trends for the project. However, for example, at the earliest stages of the software development lifecycle (when defects are less costly to identify and remedy), historical defect data (e.g., data from a past project) may not be available. For example, in some cases, there may be no past projects to use for historical defect data (or, they are not sufficiently similar to use for planning the new project). At the earliest stages of the software development cycle, when there is no or poor historical defect data to rely on, there is no additional project information available that would otherwise help overcome the lack of historical defect data. However, all complex system integration project owners need to be able to accurately project defect rates in order to effectively plan release development, test, and launch activities and costs, frequently with little or no applicable project history available.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described herein above.